Portions of the disclosure of this patent document may contain material that is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure as it appears in the Patent and Trademark Office file or records, but otherwise reserves all copyright rights whatsoever. Sun, Sun Microsystems, the Sun logo, SPARC, Java, JavaBeans and all Java-based trademarks and logos are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and other countries.
This invention relates to computing systems, and more particularly to the architecture and environment for computing and applications executing therein.
Computers are used to send and receive data using a transport mechanism or communications network. The Internet is one example of a transport mechanism and other examples include local area networks (LANs) and wide area networks (WANs). Using a network, a software application (a sender) that resides on one computer system can exchange information (e.g., corporate data or executable code) with a software application (a receiver) that resides on a remote computer system, for example. The exchange of information between computers typically occurs between a xe2x80x9cserver applicationxe2x80x9d that provides information or services, and a xe2x80x9cclient applicationxe2x80x9d that receives the provided information and services.
A problem with existing server applications is that they must be pre-configured to include the information that they are to provide to a client application. Further, issues such as transmission efficiency and security are raised when information is exchanged between computers. Transmission inefficiencies are especially apparent where information is communicated over a long distance and/or lower speed or bandwidth lines. Further, where transmission is being received by a computer system, security measures are typically used to ensure that the transmitted information (e.g., program code) does not corrupt the computer system. Unfortunately, security measures can restrict access to the computer system""s resources which can hinder an application""s efficiency and usability.
As will be discussed below, computing environments that use an application architecture initially developed for use with the Internet can be significantly affected by the type of medium used to form the Internet connection. The type of connection that a user has to the Internet can impact the speed at which :information is transmitted.
The application architecture that is typically used in the Internet environment is referred to as a three-tier application architecture, or three-tier architecture. The three-tier architecture was originally designed to allow a client to have access to data and applications. In this architecture, a client communicates requests to a server for data, software and services, for example. The three-tier architecture includes a database tier that includes a database server, an application tier that includes an application server and application logic (i.e., software application programs, functions, etc.), and a client tier. The application server responds to application requests (e.g., a request for a software applet, etc.) received from the client. The application server forwards data requests to the database server.
The number of tiers that are required for an application may vary. For example, a calculator application might only involve the client tier. That is, if the calculator application software and data are resident on the client, there is no need to access the application or database tiers. An application that makes use of persistent storage such as a word processing application and the documents created therein may involve both the client and the application tiers. An enterprise""s application (e.g., an accounting or personnel) may involve all three tiers as data that is used by the application may be stored in a database.
FIG. 1 provides an overview of a three-tier architecture. Client tier 102 typically consists of a computer system that provides a graphic user interface (GUI) generated by browser 106. Browser 106 generates a display from a specification of GUI elements (e.g., a file containing input, form, and text elements defined using the Hypertext Markup Language (HTML) and/or by an applet (i.e., a program such as a program written using the Java programming language that runs when it is loaded by the browser).
Application server 110 is pre-configured to include those applications that are needed by its clients. In an effort to keep the size of the client minimal or xe2x80x9cthin,xe2x80x9d applets that are executed in client tier 102 generally do not include any significant application logic. Application server 110 is pre-configured to include the application logic that is not included in client tier 102. The majority of an application""s functionality is performed by the application logic that resides on and is managed by application server 110 in application tier 116. Database tier 118 contains the data that is accessed by the application logic in application tier 116. Database server 112 manages the data, its structure and the operations that can be performed on the data and/or its structure.
Application server 110 and database server 112 reside in production data center 108. Application server 110 can be pre-configured with applications such as a corporation""s accounting, personnel and payroll applications, for example. Application server 110 manages requests directed to the applications that are stored on application server 110. Database server 112 manages the database(s) that manage data for applications. Database server 112 responds to request to access the accounting, personnel and payroll applications"" data, for example.
Connection 104 is used to transfer the graphical user interface layer to client tier 102 and to transmit enterprise data between client tier 102 and production data center 108. The client tier can communicate with the application tier via a Remote Method Invocation (RMI) application programming interface (API) available from Sun Microsystems. The RMI API provides the ability to invoke methods, or software modules, that reside on another computer system. Parameters are packaged (or marshalled) and unpackaged (or unmarshalled) for transmittal to and from the client tier. Connection 114 represents the transmission of requests for data and the responses to such requests from applications that reside in application server 110.
In a typical computing environment, production data center 108 is located at a centralized site. In this way, applications can be centrally managed such that updates can be made and a standardized application base can be provided to users. However, an application""s users can be spread across a wide geographical area. Thus, client tier 102 is not necessarily located at the same site or proximately connected to application server 110 (e.g., via a local area network, or LAN). Information may be transmitted, for example, via a wide area network (WAN) or the Internet that involve remote transmissions (e.g., overseas) and lower bandwidth communication technologies (e.g., modem) which can result in unacceptable transmission times. Transmission times are of concern since both data and application code may be transmitted between client tier 102 and application server 110 in the three-tier architecture.
The three-tier architecture can be used with various types of networks (e.g., Internet and intranet). Typically, client tier 102 communicates with production data center 108 via browser 106 which issues a request of application server 110. The client can request a resource that is identified by a uniform resource locator (URL) designation. For example, the URL can identify a page definition (e.g., an HTML document) that browser 106 uses to generate a display, or the URL can identify an applet (i.e., executable program code) which is run inside browse 106.
The information that is represented by a URL is downloaded to client tier 102. Thus, if a corporate application requires multiple downloads (e.g., multiple page definitions and/or applets) to run within client tier 102, the downloading process is inefficient when application server 110 is remote and/or slower transmission rates are used.
Security measures adopted for use with the application architecture limit the applications that have been developed according to this architecture. For example, an application""s efficiency and/or usability can be impacted as a result of security measures. Further, there are issues of security concerning the transmission of information. From the perspective of client tier 102, for example, it is necessary to ensure that the information that is being received is xe2x80x9ctrusted.xe2x80x9d That is, it is important to ensure that client tier 102 is not corrupted by unauthorized software executing in client tier 102. Further, it is important to ensure that a client that attempts to access production data center 108 can be trusted with the corporation""s data and applications.
Optimally, client tier 102 executes only those applets that have been received from a known and trusted source (e.g., production data center 108). A level of trust can be achieved between a client tier 102 and production data center 108 such that data and applets can be transmitted freely between client tier 102 and production data center 108. However, this paradigm is limiting and does not always occur in practice. Browser 106 may request an applet from a source other than production data center 108, for example. If an applet is allowed to execute unchecked in client tier 102, it introduces the potential for serious breaches of security and/or malicious access to the data and resources.
Security models or approaches have been adopted to limit the damage that may be caused by a breach of security and maliciousness. One such security approach, referred to as the sandbox security model, limits the access given to applets from an xe2x80x9cuntrustedxe2x80x9d (i.e., unknown) source to only its namespace (e.g., operating system-assigned boundaries of a program such as the addressable memory).
An xe2x80x9cuntrustedxe2x80x9d applet or software program is allowed to access only memory or other computer resources that are in its namespace. By limiting an xe2x80x9cuntrustedxe2x80x9d applet to its own namespace, the applet can be prohibited from modifying areas of memory assigned to other applets or applications, for example.
Further, an applet may be prohibited from establishing a connection to (and/or downloading code from) a server (e.g., file or printer servers) other than the one from which it was retrieved. Client tier 102 may be forced to access another server via application server 110. To make a request of a file server, for example, client tier 102 sends the request to application server 110 which forwards the request to the file server. This is inefficient particularly when the file server adjacent to client tier 102.
Further, in the sandbox approach, printing is accomplished by displaying material to be printed in browser 106 and relying on the user to print the material using the print functionality available in browser 106.
The sandbox approach has clear disadvantages. An applet that is confined to its namespace cannot access information that is stored in a local file system. Further, confined applets cannot pool or share resources such as memory.
Another security approach uses signatures or other forms of certification to certify that an applet is from a known source. An xe2x80x9cuntrustedxe2x80x9d applet can become a xe2x80x9ctrustedxe2x80x9d applet, if its digital signature can be verified by, for example, client tier 102. Verification can be accomplished with digital signatures using a public key/private key encryption technique. The recipient of the information (e.g., client tier 102) uses the digital signature and a public key (a key generated from the private key and distributed to the public) to verify the digital signature thereby verifying the information.
Signed applet support is not provided by all clients. To support digitally signed applets, it is necessary for client tier 102 to include the ability to verify the signature. Many currently available browsers do not have such a capability.
In addition to the efficiency and security issues, in the three-tier model each application must log in to application server 110 separately. There is no ability to store user information (e.g., profile information) in client tier 102 or elsewhere so that it can be used for subsequent applications.
One or more embodiments of the invention comprise a computing environment that offers a level of decentralization wherein application code resident on a remote application server can be distributed to a local server, or local application server, that services a client. A local application server can be dynamically configured to serve its clients based on requests for application code and/or services. Further, application code that is downloaded to a client from the local application server can be trusted such that access to the local application server""s resources can be given to the downloaded application code. Efficiencies can be achieved for the transmission of information.
Using embodiments of the invention, it is not necessary to pre-configure the local application server to satisfy a request of the server. The local application server can be configured dynamically (e.g., as needed) in response to requests. For example, there is no need to install application code or services on the local application server in anticipation of a request. If the local application server is not configured to handle a request, the local application server dynamically configures itself to satisfy the request.
A request for information, such as application code (e.g., an applet) by a client, can be serviced by the local application server with its existing configuration or a new configuration. If the local application server""s configuration includes the requested application code, the local application server satisfies the request using its existing configuration. If the local application server""s configuration does not include the requested application code, the local application server attempts to locate the requested application code (e.g., from another application server). When the requested application code is located, it is transferred to the local application server. The local application server retains a copy of the application code and forwards a copy to the client. Thus, if a subsequent request is made for the application code, it can be satisfied by the local application server (without accessing another application server).
The local application server can further be dynamically configured with services that can satisfy a client request. When a service request is received from the client, the local application server attempts to satisfy the request using a service that resides on the local application server. If the requested service is resident on the local application server, the local application server forwards the request to the service. There is no need to reconfigure the local application server.
If a request is for a service for which the local application server is not already configured, the local application server determines whether the service resides elsewhere (e.g., on another server). If the local application server finds the service, it determines whether the service can be acquired from its current location. If so, the service is copied to the local application server and is used to satisfy the client""s request.
Where the requested service cannot be transferred to the local application server, the local application server establishes a proxy for the service. The proxy resides on the local application server and forwards the client request to the service that resides on the other application server. If a response is generated by the service, the response is sent to the proxy on the local application server and forwarded to the client. Thus, where a proxy is used, the client need not be aware of the service""s actual location. The client is unaware that the requested service does not reside on the local application server.
In embodiments of the invention, the local application server includes an application locator, a service locator, a download service and none or more local services. The application and service locators are used by the local application server to locate application code and services (respectively) when a request is made that cannot be satisfied using the local application server""s current configuration. Services that are downloaded to the local application server can be used by the local application server to satisfy a request.
The local application server can be configured with proxy services as needed. A proxy service acts as proxy for a service that resides elsewhere (e.g., on another server). A proxy service is used when, for example, a service cannot be transferred to the local application server. A service request is forwarded by the proxy service to the service. The service sends a response, if any, to the proxy service for forwarding to the requester.
The local application server can be configured with application software as needed. When, for example, a client requests application code, the local application server can obtain the application code, if it does not already have the requested application code. Application code that is acquired by the local application server is retained and can be used to satisfy a subsequent request for the application code, if any.
The local application server can be configured to include local services such as print, file, login or profile services that can be shared by multiple applications. Where the local application is configured to include local services, a client request for a local service is forwarded by the local application server to the local service.
One such local service allows a client to log in to the local application server. During a login process, the client establishes its identity which is stored on the local application server and can be used for multiple applications and information requests. The local server generates a credential for the client that can be used to authorize access to any application server and/or service requested by the client.